In the software industry, designing of software programs typically begins with a modeling stage of the subject system. The UML is a visual modeling language (with formal syntax and semantics) for communicating a model or conceptualization. The UML syntax enables software designers to express (specify and document) the subject problems and solutions in a standardized manner. The UML semantics enable knowledge about the subject system to be captured and leveraged during the problem solving phase.
In that light, in UML or modeling languages generally, diagrams can be described as a graphical view on some semantic data. They are used to visualize the data in a way that is understandable to the user. An example is the UML class diagram. A diagram's purpose is to convey some specific aspect or topic about the data it is displaying. Typically the user describes this topic when he is creating the diagram using a tool. Briefly, diagramming tools are used to create and maintain diagrams. Tools typically maintain consistency across diagram types.
Topics can be generated or contributed from a variety of places. A tool in the user's environment could contribute topics. The topics that are available can change based on the user's selected context and availability of tools in the user's environment.
In the case of a UML class diagram, the user may wish to create an inheritance diagram of a particular class. The user may use a tool to create a view of the class and then expand on its relationships based on the generalization relationship type. Once completed, the user has a nice diagram that describes the topic of inheritance for the context of the initial class. The problem is that the core knowledge of what the topic the diagram is trying to represent resides in the user's mind. The user may add notes to the diagram to give an indication of its purpose, but the diagram has no innate knowledge of the topic it is trying to represent. Consequently, if the inheritance of the class changes or new classes are added to the inheritance tree, the user must go back and manually maintain the diagram to keep its topic synchronized with the underlying model.
In order to persist a diagram, one needs to store a set of graphical elements that can represent the nodes and arcs (boxes/lines) that form the context that is displayed. In the UML class diagram example, when a user adds a class or generalization view to the diagram, this is adding a notation element that stores the particular layout constraints (position, extend/bend-points, etc.). So the file for the class diagram topic would contain a set of notation elements for the class views and generalization connections with corresponding semantic references to the elements they represent. Any time that information is persisted to a common file, introduces issues in a team development environment that is under source control (source files are checked into a source control system such as CVS or ClearCase). Team members can concurrently make edits to the common file which can precipitate conflicts and resulting merges when the edits are checked in to the source control system. Merges are inherently a dangerous operation that should be avoided if at all possible.